既然提到遊戲引擎架構，對於遊戲引擎感興趣的人或許對於接下來這張圖有點印象。筆者還記得，當時正處於翻閱資料學習、構想的過程，為了對於基本架構有初步的理解找來了《Game Engine Architecture》，才剛翻閱沒多少篇幅，導論的末尾處赫然出現一個龐然大物...
這張圖便是遊戲引擎之中的運行時組件的架構圖，會強調「之中」的原因是，遊戲引擎通常是由運行時組件與工具套件兩部分構成的。
我們稍微偏題一下來講解運行時組件與工具套件。昨天的文章中我們初步的了解了遊戲引擎的概念，遊戲引擎提供可重複使用的軟體組件來重新包裝出一個新的遊戲，因此本質上遊戲引擎是架構在一個遊戲上面的，這也是運行時組件的這部分。而實際上，這個架構並不足以使其成為一個完整功能的遊戲引擎，舉例來說，有許多輸入遊戲引擎的數據，例如數位內容創作(Digital Content Creation，DCC)，可以是一個模型、一張美術圖、一段音頻等等，它們有著各式各樣的檔案格式。而在成為被遊戲所利用的資產(Aseet)之前，我們更希望的是能夠將其轉化成容易讀取的標準格式抑或是自定義的格式。又或者，我們雖然有了運行時組件來運行遊戲，但仍需要一些工具來編輯、調適所創作的遊戲世界，而這些部分便屬於工具套件的範疇，這些工具可以是獨立的軟體、可以建構在運行時引擎的低階軟體層又或是直接嵌入在遊戲之中等等。而上面那張龐大的架構卻也僅是運行時組件的部分!
話又說回來，我們真的需要從這張圖開始嗎?
別誤會，上圖的確是一個完整、詳細的架構圖。但我們的目的是先認識、預覽架構的組成，就像昨天文章所說的，我們將會一遍又一遍的來複習這個架構。那麼現階段我們或許可以用更簡單、直觀的方式來認識這張圖。
簡潔明瞭的五大架構，這是參考自《Game 104》課程裡的架構。筆者很喜歡該課程裡老師對於架構的說明、解釋。這裡就讓我們來看看如何來理解這張圖吧!
再解釋每一層的含意之前，讀者們可以先來假設一個完整功能、架構的遊戲引擎呈現在你面前，而我們將從最表面開始，對著這個遊戲引擎自上而下慢慢的解析。
Tool Layer :
首先映入眼簾的，肯定是那擁有各種工具、功能的編輯器。 工具層，也是在上面被我們分類成工具套件的部分功能。在使用引擎製作遊戲的過程中，透過呈現出來的圖形化使用者介面(GUI)來操作、編輯遊戲，也是這層代表的涵義。
Function Layer :
從編輯器向下分析，我們接著思考，要如何讓編輯器的內容運作起來?對於畫面，我們需要將其渲染到螢幕上、對於遊戲內容，我們需要物理引擎計算實體的運動又或者對於編輯器，我們需要提供GUI給使用者。而如何去「實現」使用的工具，正是功能層所探討的。
Resource Layer :
讓我們繼續走下去，在運行功能之下，還有什麼我們沒注意到的呢? 渲染的資源哪裡來、骨骼動畫怎麼去讀取、一個一個的實體、角色，他們的資料又是怎麼儲存? 在各種功能之下，這些資產(asset)的讀取、儲存方式便是資源層。
Core Layer :
在核心層中，需要實現的就是相對底層的功能了。遊戲引擎中，內存管理、多執行緒管理、實現功能使用到的資料結構抑或是實現物理引擎當中的數學公式。我們可以透過核心層來架構在它之上的其他功能、層。
Platform Layer :
進行到核心層時架構已經是相當完善了，因此這一層相對容易的被遺忘。在建立核心之前，我們還有一些問題需要考慮，那便是不同系統、不同平台上的問題。就像是在windows、Linux上建立視窗會需要呼叫不同的底層API，又或者說渲染上面windows有directx、mac有metal等等。去考慮、注意多平台的實現就是平台層的使命了。
到這裡，我們已經基礎的簡介了這五層架構了。然而，在Runtime game engine architecture那張圖我們也看見，實際上的遊戲引擎是一個大架構。因此，接下來幾天的部分將會把Runtime game engine architecture的架構與這五層架構做對照與結合，進行一個概念的統整。
開學之際，比較忙一點。前面的文章可能偏文字居多(比較好解決?!)，老實說，實作的部分我僅到可以渲染、讀取模型、GUI的部分。在我的規劃中還有不少還沒整合進去的功能(物...物理引擎好複雜QQ)，忙完開學的準備工作後，看來是有得忙ㄌ :> ! 我已經看到我半死不活的未來了
勉勵自己。
iThome鐵人賽
看影片追技術